workflow: Hand a task names each lane's Project in its pick list - #2242

…2255)

Written-by: Dev-4
Fixes ThinkFlowLab#2254

Owner: Dev4
Reviewer: Birfy
Tier: T2
Claim-Id: 860a1014446b40ccb2e6300985f9d78e
Branch: dev/4-p463-assign-names-target
Base: 575fadf
Tree: d5e92ac
Verified commit: local `49261b05b3dc120dd722799d324dc5c515f2178e` (not
on the remote; the same tree as `Tree` above, pushed as
`c5f7e5dbe77002f45b7ff9f0e42cffb1234c5a1d`)
Pushed head: c5f7e5d
Files: 4 changed, +89/−8

## The defect

**Hand a task to a Workflow** gained two ways to tell two lanes apart —
the Project badge on every target row (`ThinkFlowLab#2242`) and the Project on the
row a lane's own name sits in (`ThinkFlowLab#2241`) — but the confirm button still
read `Assign` alone (`plugins/workflow/client.js` base :1504, tip
:1512–1513). With two lanes that share one name, the identifying row
scrolls out of the dialog's footer exactly when the person presses the
button, so the last thing read before the click cannot say which lane
the card goes to.

## Red first, on live main `575fadf3`

Clean tree at `575fadf346e4297c641f74a5d79244d1ccf0cb58` with only
`plugins/workflow/test/client.test.js` carrying the new cases (base
sources, so the button still reads `Assign`):

- `plugins/workflow/test/client.test.js` → **404 tests / 401 pass / 3
fail**
- `not ok 208 - ThinkFlowLab#2254: two lanes with one name: the confirm button names
the picked lane and its Project` — `the default lane's Project is on the
button, saw Assign` (`expected: true`, `actual: false`)
- `not ok 209 - ThinkFlowLab#2254: a Bot target names the Bot on the confirm button`
— `expected: 'Assign to Writer Bot'`, `actual: 'Assign'`
- `not ok 210 - ThinkFlowLab#2254: the named confirm button posts the same assign
body` — `precondition: the second lane is the target` (`expected: true`,
`actual: false`); its own body assertion is the regression guard for the
unchanged `workflow/assign` payload, and it is the label line that fails
on the base.
- The fixture is two lanes both named `Release lane`, one in Project
`Alpha` and one in `Beta`: the default pick must name `Alpha`, picking
the second must name `Beta` and drop `Alpha`, a Bot target must name the
Bot, and the confirm click must still post exactly one `workflow/assign`
with `{ workflowId, taskId, title }`.

The base already carries `ThinkFlowLab#2252`'s cases, so the three new failures sit
at 208/209/210.

## The fix

The footer button names the target it is about to use
(`plugins/workflow/client.js` tip :1512–1513, the label reads
`targetName`, resolved once per render at tip :1451–1454):

```js
targetName ? tr('Assign to {target}', { target: targetName }) : tr('Assign')
```

`targetName` is resolved once per render from the same state the click
posts: the Bot's name for a `bot:<id>` target, else the picked lane's
name with its Project — `Release lane · Beta` — else `''`. A dialog with
no target keeps today's plain `Assign`, still disabled (`ThinkFlowLab#2245`'s
behaviour, pinned by that case). Nothing else moves: `canAssign`,
`target`, `taskId`, the submit body and the `ThinkFlowLab#2244` expanders are
byte-identical.

- `plugins/workflow/client.js` (+10/−1): the label and its three-line
comment, plus the `Assign to {target}` entry in the plugin's own zh
fallback dictionary.
- `plugins/workflow/test/client.test.js` (+77/−6): the three new cases,
plus the six places that found the button by the exact text `Assign` now
match the same button by its unchanged prefix.
- `docs/subsystems/workflow.md` (+1/−1): one sentence stating the rule
next to the Project-badge rule it completes.
- `changelog.d/2254-hand-a-task-names-its-target.changed.md` (+1).

## Delta, file by file

| file | +/- | kind |
| --- | --- | --- |
| `plugins/workflow/client.js` | +10/−1 | written |
| `plugins/workflow/test/client.test.js` | +77/−6 | written (new cases
and the finder prefix) |
| `docs/subsystems/workflow.md` | +1/−1 | written |
| `changelog.d/2254-hand-a-task-names-its-target.changed.md` | +1 |
written (new) |
| **total** | **+89/−8** | 4 files, no generated file |

`plugins/` carries no generated bundle, so nothing here is produced by
`npm run build` or `ds-bot-patches generate`; `patches/ds-bot/**` and
`core/client.js` are untouched, and `node scripts/ds-bot-patches.mjs
generate` after the edit left `patches/` byte-identical.

## What I ran at local `49261b05b3dc120dd722799d324dc5c515f2178e`
(pushed as `c5f7e5dbe77002f45b7ff9f0e42cffb1234c5a1d`)

`TZ=UTC ARCH_DOCS_BASE=575fadf346e4297c641f74a5d79244d1ccf0cb58 npm run
verify` → **exit 0**

| suite | tests / pass / fail |
| --- | --- |
| core | 2675 / 2675 / 0 |
| plugins/social | 570 / 570 / 0 |
| plugins/tree | 132 / 132 / 0 |
| plugins/timeline | 140 / 140 / 0 |
| plugins/workflow | 404 / 404 / 0 |
| `.github/scripts` | 599 / 599 / 0 |
| interop | 37 / 37 / 0 |
| live-e2e | 26 / 26 / 0 |
| **total** | **4583 / 4583 / 0** |

- After the fix, `plugins/workflow/test/client.test.js` on its own:
**404 / 404 / 0** (the base's 401 plus the three that were red).
- `arch-docs: OK (4 changed file(s))`; oxlint **0 errors** in every
suite (74/36/9/2/16 warnings, the same counts as live main; interop 1,
live-e2e 0).
- `ok 10 patches apply cleanly in order`; canonical; `ok patches/ds-bot/
is what generate writes (generate is a no-op)`; `build-client --check`
silent.

## Tier, by path (not by a label)

`createGate(risk-rules).judge(files)` over exactly these four paths,
from `575fadf3`'s `.github/agent/risk-rules.json`:

`risk-tier: T2; basis: plugins/workflow/client.js=T2,
plugins/workflow/test/client.test.js=T2,
changelog.d/2254-hand-a-task-names-its-target.changed.md=T1,
docs/subsystems/workflow.md=T0`

97 changed lines in 4 files, no generated file.

## Not run

- The smoke bench (`dev/bench.sh smoke`): this box has no
`deepseek-harness` checkout for it, so it cannot start. `core/index.js`
and `core/src/host/` are untouched by this change.
- No browser was available, so the dialog states are exercised through
the module tests rather than by clicking.

## Checkpoint

<!-- flybot:checkpoint -->
{
  "pr": 2255,
  "claim": "Dev4",
  "issue": 2254,
"summary": "The confirm button of Hand a task to a Workflow now names
the target it will use: the picked lane with its Project, or the Bot. It
read Assign alone before, so two lanes that share one name were
indistinguishable at the click. The name comes from the same state the
click posts, and the submit body stays { workflowId, taskId, title };
with no target the plain Assign stays disabled as ThinkFlowLab#2245 left it. Three
client tests drive two lanes named alike from Projects Alpha and Beta,
and a Bot target.",
  "files": [
    "plugins/workflow/client.js",
    "plugins/workflow/test/client.test.js",
    "docs/subsystems/workflow.md",
    "changelog.d/2254-hand-a-task-names-its-target.changed.md"
  ],
  "checks": {
"ran": "TZ=UTC ARCH_DOCS_BASE=575fadf3 npm run verify (4583/4583/0)",
    "result": "green",
    "at": "c5f7e5dbe77002f45b7ff9f0e42cffb1234c5a1d"
  },
"next": "T2: waiting for a PASS naming this tip; enqueue-guard will
refuse until one exists"
}
<!-- /flybot:checkpoint -->